There is currently a drive to introduce wired and wirelessly connected devices across a host of new applications. These devices might, for example, act as remote sensors to sense environmental conditions. For example, an operator of a fleet of refrigerated trucks might deploy such devices to sense and report temperature, humidity, etc, across the fleet. Devices on a given truck may communicate, with the operator's control centre via a wireless gateway (e.g. 3G or 4G) in the truck's cab. In another example, a home owner might deploy a range of different devices to monitor conditions and control other devices around the home. These might communicate, e.g. with the Internet, via a 3G or 4G gateway, WiFi router, etc. In yet another example, internal or external body mounted sensors may be used to monitor physiological data such as heart rate, blood sugar level, etc, with data being transmitted to and from internet servers via a user's 3G or 4G smartphone. Such devices are commonly referred to as “Machine-to-Machine” (M2M) devices to indicate that they provide a means for machine-to-machine communication in contrast to traditional mobile devices (e.g. UEs) whose primary function is to provide person-to-person communication. The ecosystem incorporating M2M devices has been referred to as the “Internet of Things” (IoT).
A prime requirement of M2M devices is that they be small, lightweight, and cost effective (i.e. relatively cheap) in order to facilitate their widespread use: it is estimated that in years to come there might be as many as 50 billion such connected devices. These requirements necessarily mean that a typical M2M device will be severely resource constrained, certainly as compared to a conventional UE.
For IoT/M2M systems, the numbers of devices that will need to be managed will be very large, which makes the usability of the management solution an important factor. Consider for example the case of a truck fleet operator having several hundred lorries, each with multiple M2M devices. A natural solution is to have a centralized device management point, for example a management web portal, to which the devices register and from which the devices are managed (instead of managing each device directly and individually), as well as a central data management point that is used to manage M2M data.
In addition to managing the functionality and reporting of M2M devices in a given network, the connectivity of these devices also needs to be managed, especially when the M2M devices are 3GPP capable nodes, i.e. they have their own 3GPP subscription credentials. This might be achieved, for example, using a cloud service, deployed within a cellular telephone network operator's network or as a virtual cellular network (core network). Through a platform such as this, an enterprise or even a user can manage the 3GPP subscriptions of their devices, e.g. ordering SIM cards/credentials, enabling devices etc.
Many resource-constrained M2M devices are manufactured with 3GPP credentials. These credentials may be on the device in the form of a conventional SIM card (UICC), or, as in the case of the vehicle industry, in the form of embedded UICC (eUICC), or may be part of a TRusted execution Environment (TRE) as discussed in Barriga, Luis, BEN SMEETS, and KRISTER SALLBERG. “M2M Remote-Subscription Management.” Ericsson Review 1 (2011). This use of 3GPP credentials introduces the possibility of using 3GPP Generic Bootstrapping Architecture (GBA) defined in 3GPP TS 33.220 to set up a shared secret between an M2M device and an application server (referred to as Network Application Function (NAF)). In the context of IoT/M2M, the application server may be, for example, the central device management point or central data f management point referred to above. GBA is illustrated in FIGS. 1 and 2 and will be discussed further below.
As described in 3GPP TS 33.220, GBA allows devices with 3GPP credentials to authenticate themselves to the operator and also set up shared secret keys with other application servers (NAF) on the Internet. According to the existing standards, the devices with 3GPP credentials need to support HTTP and TCP stacks. This is not optimal for all resource-constrained M2M devices as, in a real-world scenario, these M2M devices might rely on more energy-efficient and compact M2M specific application protocols, such as CoAP rather than HTTP, and might rely on UDP instead of TCP for the transport layer (e.g. to reduce power consumption and memory requirements). In some even more constrained environments, M2M devices may only perform elementary routing with Routing Protocol for Low power and Lossy Networks (RPL), leaving the task of transport layer encapsulation and data delivery to a Gateway (GW) having more resources. Either way, it is not efficient to implement the full HTTP/TCP stacks for M2M devices, when the only requirement for these protocols is the GSA, and only minimal state information is required after a GBA run (ideally only B-TID, Ks and KsNAF need to be saved, see FIG. 2).
Moreover, the problem of securely discovering a gateway (secure pairing) by a constrained device in the presence of adversaries is a common problem. This problem is enhanced in an M2M ecosystem where there are several players and different manufacturers involved. Discovering the management portal (device management service) to be used by the devices is an issue that needs to be addressed when dealing with a large set of devices.